home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 4 / BBS in a Box - Macintosh - Volume IV (January 1992) (BBS in a Box).iso / Files / Prog / M / LSC3 REVIEW < prev    next >
Encoding:
Text File  |  1988-07-26  |  10.3 KB  |  246 lines  |  [TEXT/MACA]

  1. A Review of THINK’s LightspeedC(TM) 3.0
  2.  
  3. By Jerry Whitnell
  4.  
  5. July 8, 1988
  6.  
  7. Copyright 1988 by Jerry Whitnell
  8.  
  9. All rights reserved.
  10.  
  11.  
  12.  
  13. I just received my copy of THINK’s LightspeedC Version 3.0 and after playing 
  14.  
  15. with it for a several hours will attempt to review it.  I bought the original 
  16.  
  17. LightspeedC Version 1.0 at the San Francisco MacWorld where it was 
  18.  
  19. introduced,  so I have some experience with the product.  I will assume you
  20.  
  21. are familiar with LightspeedC and so will comment only on what's changed
  22.  
  23. between Version 2.15 and Version 3.00
  24.  
  25.  
  26.  
  27.  
  28.  
  29. The Packaging
  30.  
  31.  
  32.  
  33. LightspeedC comes in a real box, unlike the shrink-wrapped manual that
  34.  
  35. delivered 2.15.  Inside are two disks (800K), two manuals and various pieces
  36.  
  37. of product literature from Symantec.  The two manuals are much smaller then
  38. then the original 8 1/2" by 11" manual.  Much of the material is from the original
  39.  
  40. manual or the 2.03 addendum, but there is also alot of new material as well.
  41.  
  42. The first manual is the User's Manual and describes both the integrated
  43.  
  44. Compiler/Editor and the Source-Level Debugger, while the second is dedicated
  45.  
  46. to the Standard I/O Library supplied for UNIX(TM) compatibility.
  47.  
  48.  
  49.  
  50.  
  51.  
  52. The Compiler/Editor
  53.  
  54.  
  55.  
  56. The Editor portion of the compiler appears to be completely unchanged from
  57.  
  58. the 2.15 version.  The compiler, however has many useful changes.  The most
  59.  
  60. obvious are those for the source-level debugger.  By setting a checked menu
  61.  
  62. option (or in the options dialog box) you can tell the compiler to generate
  63.  
  64. the information the source-level debugger needs to run your program.  When
  65.  
  66. you do this, a little bug appears by the word Name in the project window (NO!
  67.  
  68. not more bugs in my program!)  and each .c file in the list has a little diamond
  69.  
  70. placed by it's name in the project window.  By clicking on the diamond you can
  71.  
  72. enable or disable symbol table information for that file.  This is useful to save
  73.  
  74. room on your disk, since the symbol table information can double the size of
  75.  
  76. your project file (270K to almost 600K in my case).
  77.  
  78.  
  79.  
  80. The Options Dialog has undergone major surgery to reflect changes to the
  81. compiler.   Options are now stored in the Project, rather then in LSC itself, but
  82. you can specify the default options for any new Project.  The options that are
  83. new since 2.15 are in the area of code generation, precompiled headers and, of
  84. course, the debugger.  You can specify that the generated code use 68020
  85. instructions, 68881 instructions (or both), in which case the code will only work
  86. on those processors.  There is one precompiled header (called MacHeaders) that
  87. you can have LightspeedC load before each file.  This speeds up the compile since
  88. LightspeedC doesn't have to reread the .h files from the disk for every file.  The
  89. default MacHeaders comes with a subset of the Macintosh Include files, however
  90. you can also precompile a new MacHeaders to include the rest of the Macintosh
  91. header files, the standard I/O Header files or your own common header files. 
  92. Finally, one can specify whether to include the strings in the DATA resource or
  93. (as in 2.15) include them in a separate STRS resource.  Including it in the DATA
  94. resource allows smaller code since the strings can be referenced off of A5, but
  95. limits the total strings+data to be 32K.  Leaving the strings in the STRS resource
  96. allows you unlimited strings (but still only 32K of data), but you pay the price of
  97. larger code.  I'll comment on the debugger options when I describe the debugger.
  98.  
  99.  
  100.  
  101. The Project Type Dialog box has also received many new fields.  From it, you can
  102. now control the MultiFinder flags and default size fields for your application.  If
  103.  
  104. you are building a Desk Accessory or Driver, you can specify you want it
  105. multi-segment and set the flags as well.  Finally for the code resources, you can
  106. also specify the attributes and whether you want to use the default header or add
  107. one of your own.
  108.  
  109.  
  110.  
  111. Other minor changes include "Smart Linking" is now an option during the link
  112. program phase, selected by a check box in the Save File SF dialog.
  113.  
  114.  
  115.  
  116. The other feature that didn't change was the inline assembler.  A major lack for
  117. 3.0 is the lack of support for 68020, 68881 and 68851 assembly instructions.
  118.  
  119. A slightly less major lack is a Print All commands to match the Save All and
  120. Close All.
  121.  
  122.  
  123.  
  124. The compiler itself seems to be slower then the 2.15 compiles.  Event with the
  125. source level debugger turned off, the compiler ran 3 to 4 thousand lines a second
  126. slower then the 2.15 version.  Rebuild the project with LSC 3.0 (instead of using
  127. an imported 2.15) helps alot, but it is still not as fast.   Overall compile times
  128. are faster due to removal of all the extra .h files the MacHeaders replaced.  My
  129. tests showed about a 25% improvement, your mileage may vary.
  130.  
  131.  
  132.  
  133.  
  134.  
  135. The Debugger
  136.  
  137.  
  138.  
  139. And now, the moment you all have been waiting for...   Once you've selected the
  140. debugger option and recompiled all your files, all you have to do is select Run and
  141. up pops the LightspeedC Debugger.  But don't forget to load MultiFinder,
  142. otherwise your program will run without the debugger.  
  143.  
  144.  
  145.  
  146. When you Run your Project, LightspeedC finds and launches both your program and
  147. the debugger.  Control is given to the debugger, and it puts up two windows and
  148. several menus.  The window on the left is the source code window and will
  149. display the first page of text of your program.  The right-hand window is the
  150. data window, more on it in a moment.  
  151.  
  152.  
  153.  
  154. The text window is a standard text display window with scroll bars, but several
  155. extra features.  Down the left hand side is a black arrow which points at next C
  156. source statement to be executed.  Between the arrow and the left hand side of
  157. the window are a column of open diamonds.  These represent executable
  158. statements, statements that generate no code (such as declarations and
  159. comments)  have no diamond next to them. In the bottom left-hand corner is the
  160. name of the current function the text comes from.   Across the top are a row of
  161. square buttons that control program execution.  These are Go, Step, In, Out, Trace
  162. and Stop.  Go tells your program to take off and run, Trace steps one source
  163. statement, In steps into a function (as does Trace), Out will return from the
  164. current function to the caller and Step steps over function calls, stopping at the
  165. next source statement after the function.  You can go into Auto-step or
  166. Auto-Trace by holding down the Command or Option key and clicking on the Trace
  167. or Step buttons.  This will cause your program to continue updating the debugger
  168. window while executing until you click the Stop button or
  169. Command-Shift-Period.
  170.  
  171.  
  172.  
  173. You can click on the diamonds (turning them black) which will cause the program
  174. to stop executing when it reaches the statement the diamond marks.  You can set
  175. as many breakpoints as you want by clicking diamonds.  You can also set a
  176. temporary breakpoint by holding down the Command or Option key when clicking
  177. the diamond.  This temporary breakpoint will be removed when any breakpoint
  178. (either the temporary or a permanent one) is reached.
  179.  
  180.  
  181.  
  182. The data window lets you display the value of any C expression except those that
  183. have side effects in any of several formats.  Simple objects such as ints, longs
  184. and pointers can be displayed as numbers, characters or (for pointers) strings. 
  185. Structs, arrays and unions are identified by indicators (struct, [], and union) and
  186.  
  187. the address of the object.  double clicking on the data portion will bring up a
  188. separate window that displays the fields of the structure.  You can repeat this ad
  189. nasum or until memory in the debugger runs out.  One nice feature is that you can
  190. case types (just like real C) so you can display data using different types. 
  191. Another nice feature is it knows all the preprocessor symbols as well as the C
  192. symbols.  Finally, by default the values of each expression are updated on entry
  193. to the debugger.  However you can place a lock on an expression which prevents
  194. the value from being updated.  This is useful to watch how a value changes
  195. because of some operation or function.
  196.  
  197.  
  198.  
  199. One features combines the data windows and the breakpoint window.  By
  200. selecting a statement in the text window and an expression in the data window
  201. one can make a conditional breakpoint that breaks only when the expression
  202. evaluates to non-zero.  Otherwise your program keeps executing.
  203.  
  204.  
  205.  
  206. Finally there is some limited communication between LSC (which is still
  207. executing) and the debugger.  By selecting a menu option in the debugger, you can
  208. bring up the file you are executing from in a LSC editor window and edit it. 
  209. Similarly, you can select a file in the LSC project  and return to the debugger
  210. bringing it up in the text window.  This latter is a clumsy but useful way to set
  211. breakpoints in a file other then the one you are executing.
  212.  
  213.  
  214.  
  215. You can (via the Monitor command) also enter low-level debugger such as TMON or
  216. MACSBUG.  LSC still comes with MACSBUG, but they removed the section in the
  217. manual on it so you're on your own.
  218.  
  219.  
  220.  
  221. Finally if you fortunate enough to have both a Mac II and a second monitor, you
  222. optionally tell the debugger to bring up the windows on the second screen.
  223.  
  224.  
  225.  
  226. All-in-all, I have mixed feelings about the debugger.  There are lots of useful
  227. features in it, but I have lots of nits to pick with the user interface.  For
  228. example, as mentioned above, there is only one text window and to bring up the
  229. text from other files you must go back to LSC (unless you execute code from that
  230. file in which case it is automatically displayed in the text window).  And while
  231. multiple data windows are allowed, only the original one can have data entered
  232. into it.  The others only display the fields of structures that you have opened. 
  233. And while there is a Windows menu, the only two windows that you can select
  234. from it are the two original windows!  If you open another to display the fields
  235. of a structure, it doesn't get added.  Get enough windows and things get hard to
  236. find.  Finally, I can't resist playing arm-chair quarterback and wonder why the
  237. debugger is a separate application and not integrated with the editor/compiler. 
  238. It seems the current design leads to kludges and lots of wasted memory.
  239.  
  240.  
  241.  
  242. However the system works well together and in spite of the criticisms it does a
  243. good job of helping debug your programs.  And one nice feature is that it is
  244. guaranteed to make any user of Microsoft's QuickC or Borland's TurboC eat their heart out.
  245.